Corporations, such as financial institutions, are required by law to produce financial reports and disclosures that comply with government regulations. For example, the Sarbanes-Oxley Act of 2002 (“Act”) requires internal controls for assuring the accuracy of financial reports and disclosures and mandates audits and reports based on those controls. Under Section 404 of the Act, management is required to produce an internal control report as part of each annual report, and the report must affirm the responsibility of management for establishing and maintaining adequate internal control structure and procedures for financial reporting.
Many financial institutions have application level audit trails, but these alone do not provide reasonable assurance that data was not changed via another source external to the financial application. One aspect for ensuring data integrity is the ability to generate a complete audit trail of all changes made to the data, regardless of where the change originated.
A key element for compliance with the Act is separation or segregation of duties, which mandates that more than one person must complete a task for producing financial reports. However, separation of duties is both costly and time-consuming. In current systems, separation of duties may be used to implement an appropriate level of checks and balances upon the activities of individuals to prevent fraud and errors in production. Current systems may achieve separation of duties by disseminating the tasks and associated privileges for a specific business process among multiple users.
In practice, financial institutions may use role-based access control in information technology systems where separation of duties is required. Control of data changes in a database may require financial institutions to assign different steps in a data change process to individual personnel. For example, a first user or group of users may identify a needed data change. When a data change is identified, a second user or group of users may receive the requirements for the data change from the appropriate business unit, create a test script for the data change, and execute the test script in a development environment.
After creation and execution of the test script, the script may be transmitted to a third user or group of users for approval in a test environment. The third user or group of users may review the results of the test and approve them. If the review fails, the script may be returned to the second user or group of users in the development stage for correction and subsequent execution and transmission to the third user or group of users. If the third user or group of users approves the script, the script may be transmitted to a fourth user or group of users for approval in a production environment. The fourth user or group of users may also review the results of the test and approve them. If the review fails, the script may be returned to the second user or group of users in the development stage for correction, and the process begins again. If the fourth user or group of users approves the script, the script may be verified at this time.
Accordingly, numerous users or groups of users are involved in processing a single data change in a database. Because of the number of steps involved and the volume of users needed to create, execute, approve, and verify each change, this process may take many hours if not days to complete. On average, this process may take 8-24 hours to execute a single data change.
Accordingly, systems and methods are needed that reduce the amount of time and the number of users associated with creating, processing, verifying and approving data changes, while still complying with regulations, among other things.